Anyway, I will explain in detail how magstripes are encoded and give several examples of the data found on some common cards. I will also cover the technical theory behind magnetic encoding, and discuss magnetic encoding alternatives to magstripes (Wiegand, barium ferrite). Non-magnetic card technology (bar code, infrared, etc.) will be described. Finally, there will be an end discussion on security systems and the ramifications of emergent "smartcard" and biometric technologies.
First, I am going to explain the basics behind fields, heads, encoding and reading. Try and absorb the THEORY behind encoding/reading. This will help you greatly if you ever decide to build your own encoder/reader from scratch (more on that later). FERROMAGNETIC materials are substances that retain magnetism after an external magnetizing field is removed. This principle is the basis of ALL magnetic recording and playback. Magnetic POLES always occur in pairs within magnetized material, and MAGNETIC FLUX lines emerge from the NORTH pole and terminate at the SOUTH. The elemental parts of MAGSTRIPES are ferromagnetic particles about 20 millionths of an inch long, each of which acts like a tiny bar magnet. These particles are rigidly held together by a resin binder. The magnetic particles are made by companies which make coloring pigments for the paint industry, and are usually called pigments. When making the magstripe media, the elemental magnetic particles are aligned with their North-South axes parallel to the magnetic stripe by means of an external magnetic fields while the binder hardens.
These particles are actually permanent bar magnets with TWO STABLE POLARITIES. If a magnetic particle is placed in a strong external magnetic field of the opposite polarity, it will FLIP its own polarity (North becomes South, South becomes North). The external magnetic field strength required to produce this flip is called the COERCIVE FORCE, or COERCIVITY of the particle. Magnetic pigments are available in a variety of coercivities (more on that later on).
An unencoded magstripe is actually a series of North-South magnetic domains (see Figure 1). The adjacent N-S fluxes merge, and the entire stripe acts as a single bar magnet with North and South poles at its ends.
Figure 1: N-S.N-S.N-S.N-S.N-S.N-S.N-S.N-S <-particles in stripe
---------
represented as-> N-----------------------------S
However, if a S-S interface is created somewhere on the stripe, the fluxes
will REPEL, and we get a concentration of flux lines around the S-S interface
(same with N-N interface). ENCODING consists of creating S-S and N-N interfaces,
and READING consists of (you guessed it) detecting 'em. The S-S and N-N
interfaces are called FLUX REVERSALS.
||| ||| <-flux lines
Figure 2: N------------N-N-S-S-----------------S
--------- flux lines -> ||| |||
The external magnetic field used to flip the polarities is produced by a
SOLENOID, which can REVERSE its polarity by reversing the direction of CURRENT.
An ENCODING head solenoid looks like a bar magnet bent into the shape of a ring
so that the North/South poles are very close and face each other across a tiny
gap. The field of the solenoid is concentrated across this gap, and when
elemental magnetic particles of the magstripe are exposed to this field, they
polarize to the OPPOSITE (unlike poles attract). Movement of the stripe past the
solenoid gap during which the polarity of the solenoid is REVERSED will produce
a SINGLE flux reversal (see Figure 3). To erase a magstripe, the encoding head
is held at a CONSTANT polarity and the ENTIRE stripe is moved past it. No flux
reversals, no data.
| | <----wires leading to solenoid
| | (wrapped around ring)
/-|-|-\
/ \
Figure 3: | | <----solenoid (has JUST changed polarity)<>
--------- \ /
\ N S / <---gap in ring.. NS polarity across gap
N----------------------SS-N-------------------------S
^^
<<<<<-direction of stripe movement<>
S-S flux reversal created at trailing edge of solenoid!<>
So, we now know that flux reversals are only created the INSTANT the
solenoid CHANGES its POLARITY. If the solenoid in Figure 3 were to remain at its
current polarity, no further flux reversals would be created as the magstripe
moves from right to left. But, if we were to change the solenoid gap polarity
>from NS to *SN*, then (you guessed it) a *N-N* flux reversal would instantly
be created. Just remember, for each and every reversal in solenoid polarity, a
single flux reversal is created (commit it to memory). An encoded magstripe is
therefore just a series of flux reversals (NN followed by SS followed by NN).
DATA! DATA! DATA! That's what you want! How the hell are flux reversals read and interpreted as data? Another solenoid called a READ HEAD is used to detect these flux reversals. The read head operates on the principle of ELECTROMAGNETIC RECIPROCITY: current passing thru a solenoid produces a magnetic field at the gap, therefore, the presence of a magnetic field at the gap of a solenoid coil will PRODUCE A CURRENT IN THE COIL! The strongest magnetic fields on a magstripe are at the points of flux reversals. These are detected as voltage peaks by the reader, with +/- voltages corresponding to NN/SS flux reversals (remember, flux reversals come in 2 flavors).
See Figure 4.
magstripe---> -------NN--------SS--------NN---------SS------<>
Figure 4: voltage-----> .......+.........-.........+...........-.....
---------
---------- -------------
peak readout--> | | | |
--------| |----------| |----<>
The "peak readout" square waveform is critical. Notice that the voltage
peak remains the same until a new flux reversal is encountered.
Now, how can we encode DATA? The most common technique used is known as Aiken Biphase, or "two-frequency coherent-phase encoding" (sounds impressive, eh?). First, digest the diagrams in Figure 5.
Figure 5: ---------- ---------- ----------
--------- | | | | | | <- peak
a) | |--------| |--------| | readouts
* 0 * 0 * 0 * 0 * 0 *<>
----- ----- ----- ----- ----- -
| | | | | | | | | | |
b) | |----| |----| |----| |----| |----|<>
* 1 * 1 * 1 * 1 * 1 *<>
----- ---------- ----- ----- -
| | | | | | | | |
c) | |----| |--------| |----| |----|<>
* 1 * 0 * 0 * 1 * 1 *<>
There you have it. Data is encoded in "bit cells," the frequency of which
is the frequency of '0' signals. '1' signals are exactly TWICE the frequency of
'0' signals. Therefore, while the actual frequency of the data passing the read
head will vary due to swipe speed, data density, etc, the '1' frequency will
ALWAYS be TWICE the '0' frequency. Figure 5C shows exactly how '1' and '0' data
exists side by side.
We're getting closer to read DATA! Now, we're all familiar with binary and how numbers and letters can be represented in binary fashion very easily. There are obviously an INFINITE number of possible standards, but thankfully the American National Standards Institute (ANSI) and the International Standards Organization (ISO) have chosen 2 standards. The first is
The sum of the 1's in each case is odd, thanks to the parity bit. If the read system adds up the 5 bits and gets an EVEN number, it flags the read as ERROR, and you got to scan the card again (I KNOW a lot of you out there ALREADY understand parity, but I got to cover all the bases...not everyone sleeps with their modem and can recite the entire AT command set at will, you know). See Figure 6 for details of ANSI/ISO BCD.
Figure 6: ANSI/ISO BCD Data Format ---------<>
--Data Bits-- Parity
b1 b2 b3 b4 b5 Character Function<>
0 0 0 0 1 0 (0H) Data
1 0 0 0 0 1 (1H) "
0 1 0 0 0 2 (2H) "
1 1 0 0 1 3 (3H) "
0 0 1 0 0 4 (4H) "
1 0 1 0 1 5 (5H) "
0 1 1 0 1 6 (6H) "
1 1 1 0 0 7 (7H) "
0 0 0 1 0 8 (8H) "
1 0 0 1 1 9 (9H) "
0 1 0 1 1 : (AH) Control
1 1 0 1 0 ; (BH) Start Sentinel
0 0 1 1 1 < (CH) Control
1 0 1 1 0 = (DH) Field Separator
0 1 1 1 0 > (EH) Control
1 1 1 1 1 ? (FH) End Sentinel<>
***** 16 Character 5-bit Set *****
10 Numeric Data Characters
3 Framing/Field Characters
3 Control Characters<>
The magstripe begins with a string of Zero bit-cells to permit the self-
clocking feature of biphase to "sync" and begin decoding. A "Start Sentinel"
character then tells the reformatting process where to start grouping the
decoded bitstream into groups of 5 bits each. At the end of the data, an "End
Sentinel" is encountered, which is followed by an "Longitudinal Redundancy
Check (LRC) character. The LRC is a parity check for the sums of all b1, b2,
b3, and b4 data bits of all preceding characters. The LRC character will catch
the remote error that could occur if an individual character had two
compensating errors in its bit pattern (which would fool the 5th-bit parity
check).The START SENTINEL, END SENTINEL, and LRC are collectively called "Framing Characters", and are discarded at the end of the reformatting process.
Figure 7: --------- ANSI/ISO ALPHA Data Format<>
------Data Bits------- Parity
b1 b2 b3 b4 b5 b6 b7 Character Function<>
0 0 0 0 0 0 1 space (0H) Special
1 0 0 0 0 0 0 ! (1H) "
0 1 0 0 0 0 0 " (2H) "
1 1 0 0 0 0 1 # (3H) "
0 0 1 0 0 0 0 $ (4H) "
1 0 1 0 0 0 1 % (5H) Start Sentinel
0 1 1 0 0 0 1 & (6H) Special
1 1 1 0 0 0 0 ' (7H) "
0 0 0 1 0 0 0 ( (8H) "
1 0 0 1 0 0 1 ) (9H) "
0 1 0 1 0 0 1 * (AH) "
1 1 0 1 0 0 0 + (BH) "
0 0 1 1 0 0 1 , (CH) "
1 0 1 1 0 0 0 - (DH) "
0 1 1 1 0 0 0 . (EH) "
1 1 1 1 0 0 1 / (FH) "<>
0 0 0 0 1 0 0 0 (10H) Data (numeric)
1 0 0 0 1 0 1 1 (11H) "
0 1 0 0 1 0 1 2 (12H) "
1 1 0 0 1 0 0 3 (13H) "
0 0 1 0 1 0 1 4 (14H) "
1 0 1 0 1 0 0 5 (15H) "
0 1 1 0 1 0 0 6 (16H) "
1 1 1 0 1 0 1 7 (17H) "
0 0 0 1 1 0 1 8 (18H) "
1 0 0 1 1 0 0 9 (19H) "<>
0 1 0 1 1 0 0 : (1AH) Special
1 1 0 1 1 0 1 ; (1BH) "
0 0 1 1 1 0 0 < (1CH) "
1 0 1 1 1 0 1 = (1DH) "
0 1 1 1 1 0 1 > (1EH) "
1 1 1 1 1 0 0 ? (1FH) End Sentinel
0 0 0 0 0 1 0 @ (20H) Special<>
1 0 0 0 0 1 1 A (21H) Data (alpha)
0 1 0 0 0 1 1 B (22H) "
1 1 0 0 0 1 0 C (23H) "
0 0 1 0 0 1 1 D (24H) "
1 0 1 0 0 1 0 E (25H) "
0 1 1 0 0 1 0 F (26H) "
1 1 1 0 0 1 1 G (27H) "
0 0 0 1 0 1 1 H (28H) "
1 0 0 1 0 1 0 I (29H) "
0 1 0 1 0 1 0 J (2AH) "
1 1 0 1 0 1 1 K (2BH) "
0 0 1 1 0 1 0 L (2CH) "
1 0 1 1 0 1 1 M (2DH) "
0 1 1 1 0 1 1 N (2EH) "
1 1 1 1 0 1 0 O (2FH) "
0 0 0 0 1 1 1 (30H) "
1 0 0 0 1 1 0 Q (31H) "
0 1 0 0 1 1 0 R (32H) "
1 1 0 0 1 1 1 S (33H) "
0 0 1 0 1 1 0 T (34H) "
1 0 1 0 1 1 1 U (35H) "
0 1 1 0 1 1 1 V (36H) "
1 1 1 0 1 1 0 W (37H) "
0 0 0 1 1 1 0 X (38H) "
1 0 0 1 1 1 1 Y (39H) "
0 1 0 1 1 1 1 Z (3AH) "<>
1 1 0 1 1 1 0 [ (3BH) Special
0 0 1 1 1 1 1 \ (3DH) Special
1 0 1 1 1 1 0 ] (3EH) Special
0 1 1 1 1 1 0 ^ (3FH) Field Separator
1 1 1 1 1 1 1 _ (40H) Special<>
***** 64 Character 7-bit Set *****
* 43 Alphanumeric Data Characters
* 3 Framing/Field Characters
* 18 Control/Special Characters<>
The two ANSI/ISO formats, ALPHA and BCD, allow a great variety of data to be
stored on magstripes. Most cards with magstripes use these formats, but
occasionally some do not. More about those later on.
Figure 8:
--------- <edge of card>
_________________________________________________________________
| ^ ^ ^
|------------------| 0.223"--|---------|-------------------------
| | | 0.353" | ^
|..................|.........|.........| 0.493" |
| Track #1 0.110" | | |
|............................|.........|... <MAGSTRIPE>
| | | |
|............................|.........|... |
| Track #2 0.110" | |
|......................................|... |
| | |
|......................................|... |
| Track #3 0.110" |
|.......................................... |
| |
|------------------------------------------------------------------
|
| <body of card>
|<>
You can see the exact distances of each track from the edge of the card, as
well as the uniform width and spacing. Place a magstripe card in front of you
with the magstripe visible at the bottom of the card. Data is encoded from
left to right (just like reading a book). See Figure 9.
Figure 9:
--------- ANSI/ISO Track 1,2,3 Standards<>
Track Name Density Format Characters Function
--------------------------------------------------------------------
1 IATA 210 bpi ALPHA 79 Read Name & Account
2 ABA 75 bpi BCD 40 Read Account
3 THRIFT 210 bpi BCD 107 Read Account &
*Encode* Transaction<>
*** Track 1 Layout: ***<>
| SS | FC | PAN | Name | FS | Additional Data | ES | LRC |<>
SS=Start Sentinel "%"
FC=Format Code
PAN=Primary Acct. # (19 digits max)
FS=Field Separator "^"
Name=26 alphanumeric characters max.
Additional Data=Expiration Date, offset, encrypted PIN, etc.
ES=End Sentinel "?"
LRC=Longitudinal Redundancy Check<>
*** Track 2 Layout: ***<>
| SS | PAN | FS | Additional Data | ES | LRC |<>
SS=Start Sentinel ";"
PAN=Primary Acct. # (19 digits max)
FS=Field Separator "="
Additional Data=Expiration Date, offset, encrypted PIN, etc.
ES=End Sentinel "?"
LRC=Longitudinal Redundancy Check<>
*** Track 3 Layout: ** Similar to tracks 1 and 2. Almost never used.
Many different data standards used.<>
Track 2, "American Banking Association," (ABA) is most commonly used. This
is the track that is read by ATMs and credit card checkers. The ABA designed
the specifications of this track and all world banks must abide by it. It
contains the cardholder's account, encrypted PIN, plus other discretionary
data.Track 1, named after the "International Air Transport Association," contains the cardholder's name as well as account and other discretionary data. This track is sometimes used by the airlines when securing reservations with a credit card; your name just "pops up" on their machine when they swipe your card!
Since Track 1 can store MUCH more information, credit card companies are trying to urge retailers to buy card readers that read Track 1. The PROBLEM is that most card readers read either Track 1 or Track 2, but NOT BOTH! And the installed base of readers currently is biased towards Track 2. VISA USA is at the front of this 'exodus' to Track 1, to the point where they are offering Track 1 readers at reduced prices thru participating banks. A spokesperson for VISA commented:
Track 3 is unique. It was intended to have data read and WRITTEN on it. Cardholders would have account information UPDATED right on the magstripe. Unfortunately, Track 3 is pretty much an orphaned standard. Its ORIGINAL design was to control off-line ATM transactions, but since ATMs are now on-line ALL THE TIME, it's pretty much useless. Plus the fact that retailers and banks would have to install NEW card readers to read that track, and that costs $$.
Encoding protocol specifies that each track must begin and end with a length of all Zero bits, called CLOCKING BITS. These are used to synch the self- clocking feature of biphase decoding. See Figure 10.
Figure 10: end sentinel
start sentinel | longitudinal redundancy check
| | |
000000000000000 SS.................ES LRC 0000000000000000
leading data, data, data trailing
clocking bits clocking bits
(length varies) (length varies)<>
THAT'S IT!!! There you have the ANSI/ISO STANDARDS! Completely explained.
Now, the bad news. NOT EVERY CARD USES IT! Credit cards and ATM cards will
follow these standards. BUT, there are many other types of cards out there.
Security passes, copy machine cards, ID badges, and EACH of them may use a
PROPRIETARY density/format/track-location system. ANSI/ISO is REQUIRED for
financial transaction cards used in the international interbank network. All
other cards can play their own game.The good news. MOST other cards follow the standards, because it's EASY to follow a standard instead of WORKING to make your OWN! Most magstripe cards other than credit cards and ATM cards will use the same Track specifications, and use either BCD or ALPHA formats.
Sorry, but magstripe equipment is hard to come by. For obvious reasons, card readers are not made commonly available to consumers. How to build one is the topic for another file (this file is already too long).
Your best bets are to try and scope out Electronics Surplus Stores and flea markets. Do not even bother trying to buy one directly from a manufacturer, since they will immediately assume you have "criminal motives." And as for getting your hands on a magstripe ENCODER...well, good luck! Those rare beauties are worth their weight in gold. Keep your eyes open and look around, and MAYBE you'll get lucky! A bit of social engineering can go a LONG way.
There are different kinds of magstripe readers/encoders. The most common ones are "swipe" machines: the type you have to physically slide the card thru. Others are "insertion" machines: like ATM machines they 'eat' your card, then regurgitate it after the transaction. Costs are in the thousands of dollars, but like I said, flea markets and surplus stores will often have GREAT deals on these things. Another problem is documentation for these machines. If you call the manufacturer and simply ask for 'em, they will probably deny you the literature. "Hey son, what are you doing with our model XYZ swipe reader? That belongs in the hands of a "qualified" merchant or retailer, not some punk kid trying to "find out how things work!" Again, some social engineering may be required. Tell 'em you're setting up a new business. Tell 'em you're working on a science project. Tell 'em anything that works!
2600 Magazine recently had a good article on how to build a machine that copies magstripe cards. Not much info on the actual data formats and encoding schemes, but the device described is a start. With some modifications, I bet you could route the output to a dumb terminal (or thru a null modem cable) in order to READ the data. Worth checking out the schematics.
As for making your own cards, just paste a length of VCR, reel-to-reel, or audio cassette tape to a cut-out posterboard or plastic card. Works just as good as the real thing, and useful to experiment with if you have no expired or 'dead' ATM or calling cards lying around (SAVE them, don't TOSS them!).
Notice that I make careful note of "common data." This is data that I noticed was the same for all cards of a particular type. This is highlighted below the data with asterisks (*). Where I found varying data, I indicate it with "x"'s. In those cases, NUMBER of CHARACTERS was consistent (the number of "x"'s equals the number of characters...one to one relationship).
I still don't know what some of the data fields are for, but hopefully I will be following this file with a sequel after I collect more data. It ISN'T easy to find lots of cards to examine. Ask your friends, family, and co-workers to help! "Hey, can I, ahh, like BORROW your MCI calling card tonight? I'm working on an, ahh, EXPERIMENT. Please?" Just...be honest! Also, do some trashing. People will often BEND expired cards in half, then throw them out. Simply bend them back into their normal shape, and they'll usually work (I've done it!). They may be expired, but they're not ERASED!
-=Mastercard=- Number on front of card -> 1111 2222 3333 4444
Expiration date -> 12/99<>
Track 2 (BCD,75 bpi)-> ;1111222233334444=99121010000000000000?
***<>
Track 1 (ALPHA,210 bpi)-> %B1111222233334444^PUBLIC/JOHN?
*
Note that the "101" was common to all MC cards checked, as well as the "B".
-=VISA=- Number on front of card -> 1111 2222 3333 4444
Expiration date -> 12/99<>
Track 2 (BCD,75 bpi)-> ;1111222233334444=9912101xxxxxxxxxxxxx?
***
Track 1 (ALPHA,210 bpi)-> %B1111222233334444^PUBLIC/JOHN^9912101xxxxxxxxxxxxx?
*<>
Note that the "101" was common to all VISA cards checked, as well as the "B".
Also, the "xxx" indicates numeric data that varied from card to card, with no
apparent pattern. I believe this is the encrypted pin for use when cardholders
get 'cash advances' from ATMs. In every case, tho, I found *13* digits of the
stuff.
-=Discover=- Number on front of card -> 1111 2222 3333 4444
Expiration date -> 12/99<>
Track 2 (BCD,75 bpi)-> ;1111222233334444=991210100000?
********<>
Track 1 (ALPHA,210 bpi)-> %B1111222233334444^PUBLIC/JOHN___^991210100000?
********
Note, the "10100000" and "B" were common to most DISCOVER cards checked. I
found a few that had "10110000" instead. Don't know the significance. Note
the underscores after the name JOHN. I found consistently that the name data
field had *26* characters. Whatever was left of the field after the name was
"padded" with SPACES. So...for all of you with names longer than 25 (exclude
the "/") characters, PREPARE to be TRUNCATED! ;)
-=US Sprint FON=- Number on front of card -> 111 222 3333 4444<>
Track 2 (BCD,75 bpi)-> ;xxxxxx11122233339==xxx4444xxxxxxxxxx=?
*<>
Track 1 (ALPHA,210 bpi)-> %B^ /^^xxxxxxxxxxxxxxxxx?
*<>
Strange. None of the cards I check had names in the Track 1 fields. Track 1
looks unused, yet it was always formatted with field separators. The "xxx"
stuff varied from card to card, and I didn't see a pattern. I know it isn't
a PIN, so it must be account data.
-=Fleet Bank=- Number on front of card -> 111111 222 3333333
Expiration date -> 12/99<>
Track 2 (BCD,75 bpi)-> ;1111112223333333=9912120100000000xxxx?
****<>
Track 1 (ALPHA,210 bpi) ->
%B1111112223333333^PUBLIC/JOHN___^9912120100000000000000xxxx000000?
* ****<>
Note that the "xxx" data varied. This is the encrypted PIN offset. Always 4
digits (hmmm...). The "1201" was always the same. In fact, I tried many ATM
cards from DIFFERENT BANKS...and they all had "1201".
(Can't leave *this* one out ;)
-=Radio Shack=- Number on front of card -> 1111 222 333333
NO EXPIRATION data on card<>
Track 2 (BCD,75 dpi)-> ;1111222333333=9912101?
*******<>
Note that the "9912101" was the SAME for EVERY Radio Shack card I saw. Looks
like when they don't have 'real' data to put in the expiration date field, they
have to stick SOMETHING in there.Well, that's all I'm going to put out right now. As you can see, the major types of cards (ATMs, CC) all follow the same rules more or less. I checked out a number of security passcards and timeclock entry cards..and they ALL had random stuff written to Track 2. Track 2 is by FAR the MOST utilized track on the card. And the format is pretty much always ANSI/ISO BCD. I DID run into some hotel room access cards that, when scanned, were GARBLED. They most likely used a character set other than ASCII (if they were audio tones, my reader would have put out NOTHING...as opposed to GARBLED data). As you can see, one could write a BOOK listing different types of card data. I intended only to give you some examples. My research has been limited, but I tried to make logical conclusions based on the data I received.
||| || || | ||| | || || | || || | | ||
| | | | | | |||| || |||| ||
The wires are NOT visible from the outside of the card, but if
your card is white, place it in front of a VERY bright light source
and peer inside. Notice that the spacings between the wires is
uniform.
REMEMBER: since all magstripes have the same magnetic remanence regardless of their coercivity, readers CANNOT tell the difference between HIGH and LOW energy stripes. Both are read the same by the same machines.
LOW-ENERGY media is most common. It is used on all financial cards, but its disadvantage is that it is subject to accidental demagnetization from contact with common magnets (refrigerator, TV magnetic fields, etc.). But these cards are kept safe in wallets and purses most of the time.
HIGH-ENERGY media is used for ID Badges and access control cards, which are commonly used in 'hostile' environments (worn on uniform, used in stockrooms). Normal magnets will not affect these cards, and low-energy encoders cannot write to them.
Other security blunders include passcard magstripes encoded ONLY with the owner's social security number (yeah, real difficult to find out a person's SS#...GREAT idea), and having passcards with only 3 or 4 digit codes.
Smartcard technology involves the use of chips embedded in plastic cards, with pinouts that temporarily contact the card reader equipment. Obviously, a GREAT deal of data could be stored in this way, and unauthorized duplication would be very difficulty. Interestingly enough, not much effort is being put into smartcards by the major credit card companies. They feel that the tech is too expensive, and that still more data can be squeezed onto magstripe cards in the future (especially Track 1). I find this somewhat analogous to the use of metallic oxide disk media. Sure, it's not the greatest (compared to erasable- writable optical disks), but it's CHEAP..and we just keep improving it. Magstripes will be around for a long time to come. The media will be refined, and data density increased. But for conventional applications, the vast storage capabilities of smartcards are just not needed.
I'm not paranoid, nor do I subscribe to any grand "corporate conspiracy," but I find it a bit unsettling that our physical attributes will most likely someday be sitting in the cool, vast electronic databases of the CORPORATE world. Accessible by anyone willing to pay. Imagine CBI and TRW databases with your retina image, fingerprint, and voice pattern online for instant, convenient retrieval. Today, a person can CHOOSE NOT to own a credit card or a bank card...we can cut up our plastic ID cards! Without a card, a card reader is useless and cannot identify you.
Paying in cash makes you invisible! However, with biometrics, all a machine has to do is watch... listen...and record. With government/corporate America pushing all the buttons. "Are you paying in cash?..Thank you...Please look into the camera. Oh, I see your name is Mr. Smith...uh, oh...my computer tells me you haven't paid your gas bill...afraid I'm going to have to keep this money and credit your gas account with it....do you have any more cash?...or would you rather I garnish your paycheck?" heh heh
Remember.... "Truth is cheap, but information costs!"
But -=RDT is gonna change all that... ;) set the info FREE!
Peace.
Usual greets to Magic Man, Brian Oblivion, Omega, White Knight, and anyone else I ever bummed a cigarette off.
(1/18/92 addition: Greets to everyone I met at Xmascon..including but not excluding Crimson Death, Dispater, Sterling, Mack Hammer, Erik Bloodaxe, Holistic Hacker, Pain Hertz, Swamp Ratte, G.A.Ellsworth, Phaedrus, Moebius, Lord MacDuff, Judge Dredd, and of course hats off to *Drunkfux* for organizing and taking responsibility for the whole damn thing. Hope to see all of you at SummerCon '92! Look for Cyber-striper GIFs at a BBS near you..heh heh)
Comments, criticisms, and discussions about this file are welcome. I can be reached at: